Skip to content

Conversation

@avrabe
Copy link
Contributor

@avrabe avrabe commented Oct 26, 2025

Problem

Windows builds failing on Windows Server 2025:
Error: Unsupported platform windows server 2025_amd64

Root Cause

Platform detection didn't normalize Windows OS names. GitHub Actions uses "Windows Server 2025" which becomes windows server 2025_amd64 after lowercasing, but registry expects windows_amd64.

Solution

Fixed platform detection in 7 toolchain files to use pattern matching:

  • wasm_toolchain.bzl
  • wasmtime_toolchain.bzl
  • jco_toolchain.bzl
  • wasi_sdk_toolchain.bzl
  • cpp_component_toolchain.bzl
  • symmetric_wit_bindgen_toolchain.bzl
  • monitoring.bzl

Now uses if "windows" in os_name instead of exact match, supporting all Windows variants.

Additional Changes

  • Enabled Windows tests in PR CI (was main-only)
  • Reduced test matrix to avoid overload

Testing

CI validates Windows Server 2025, Ubuntu, macOS builds.

Windows builds have been failing on Windows Server 2025 with error:
"Unsupported platform windows server 2025_amd64"

The issue was that platform detection did not normalize Windows OS names.
GitHub Actions now uses "Windows Server 2025" which becomes
"windows server 2025_amd64" after lowercasing, but the checksum registry
expects "windows_amd64".

Changes:
- Fixed platform detection in 7 toolchain files to normalize Windows names:
  * wasm_toolchain.bzl
  * wasmtime_toolchain.bzl
  * jco_toolchain.bzl
  * wasi_sdk_toolchain.bzl
  * cpp_component_toolchain.bzl
  * symmetric_wit_bindgen_toolchain.bzl
  * monitoring.bzl

- Note: tinygo_toolchain.bzl, wizer_toolchain.bzl, and wkg_toolchain.bzl
  already had correct implementations

- Enabled Windows tests in PR CI (was only running on main branch)
  * Reduced test matrix to latest Bazel versions only on PRs
  * This ensures Windows issues are caught early

The fix uses pattern matching ("windows" in os_name) instead of exact
string comparison, so it will work with any Windows variant:
- Windows 10, Windows 11
- Windows Server 2019, 2022, 2025
- Future Windows versions
Windows releases of wasm-tools use .zip format, not .tar.gz format.
This was causing 404 errors when trying to download wasm-tools on Windows.

Changes:
- Update wasm-tools.json: Change url_suffix from .tar.gz to .zip for all Windows entries
- Update checksums to match actual Windows .zip files:
  - v1.235.0: ecf9f2064c2096df134c39c2c97af2c025e974cc32e3c76eb2609156c1690a74 (unchanged)
  - v1.239.0: 039b1eaa170563f762355a23c5ee709790199433e35e5364008521523e9e3398 (updated)
  - v1.240.0: 81f012832e80fe09d384d86bb961d4779f6372a35fa965cc64efe318001ab27e (updated)
- Update _download_wasm_tools() to handle both .zip and .tar.gz archives

Fixes: bytecodealliance/wasm-tools Windows download errors in BCR CI
@avrabe avrabe force-pushed the fix/windows-platform-detection branch from 3e778b6 to 1795b7a Compare October 26, 2025 08:30
avrabe added 24 commits October 30, 2025 06:15
Windows wkg checksum was wrong - using old wasm-tools checksum by mistake.

Correct checksum: 930adea31da8d2a572860304c00903f7683966e722591819e99e26787e58416b
Wrong checksum: 0019dfc4b32d63c1392aa264aed2253c1e0c2fb09216f8e2cc269bbfb8bb49b5

Fixed in all 3 locations:
- checksums/tools/wkg.json
- checksums/registry.bzl
- toolchains/wkg_toolchain.bzl
Windows wac checksum was wrong for both v0.7.0 and v0.8.0.
Also added missing v0.8.0 entry to wac.json (was only in registry.bzl).

Correct checksum: 7ee34ea41cd567b2578929acce3c609e28818d03f0414914a3939f066737d872
Wrong checksum: d8c65e5471fc242d8c4993e2125912e10e9373f1e38249157491b3c851bd1336
v0.46.0 was using v0.43.0's Windows checksum (copypaste error).

Correct v0.46.0 checksum: 95c6380ec7c1e385be8427a2da1206d90163fd66b6cbb573a516390988ccbad2
Wrong checksum (from v0.43.0): e133d9f18bc0d8a3d848df78960f9974a4333bee7ed3f99b4c9e900e9e279029
…proach

- Document dependency management patterns in CLAUDE.md with clear decision matrix
- Simplify toolchain strategies to download-only (remove build/source/hybrid options)
- Migrate wasmsign2-cli to JSON registry for consistent security auditing
- Clean up JSON registry files to keep only latest + previous stable versions
  * wasm-tools: 4 versions → 2 (1.240.0, 1.239.0)
  * file-ops-component: 3 versions → 2 (rc.3, rc.2)
  * nodejs: 3 versions → 2 (20.18.0, 18.20.8)
  * wasi-sdk: 3 versions → 2 (27, 26)
  * wasmtime: 3 versions → 2 (37.0.2, 35.0.0)
- Update MODULE.bazel to use download strategy for wasm_toolchain

This establishes clear patterns:
- Multi-platform GitHub binaries → JSON Registry + secure_download
- Bazel Central Registry deps → bazel_dep
- Source builds → git_repository (when needed)
- Universal WASM binaries → JSON Registry
- NPM packages → hermetic npm

Benefits: faster builds (prebuilt binaries), easier security audits (central
checksums), simpler maintenance (one strategy per tool), clear documentation.
- Remove bazel/build/hybrid strategy support from wasm_toolchain.bzl
- Simplify to download-only strategy (matching extensions.bzl cleanup)
- Delete orphaned BUILD.wasm_tools_bazel and BUILD.wizer_bazel files
- Add these files to .gitignore to prevent regeneration
- Remove _setup_bazel_native_tools function (dead code)
- Update all strategy references and error messages

This completes the dependency management consolidation by removing
unreachable code paths and simplifying the toolchain to use only
prebuilt binary downloads from GitHub releases.
The stripPrefix was not removing .zip extension for Windows archives,
causing extraction errors on Windows CI:

  Error: Prefix "wit-bindgen-0.46.0-x86_64-windows.zip" not found
  Should be: "wit-bindgen-0.46.0-x86_64-windows"

This fix adds .replace(".zip", "") alongside .replace(".tar.gz", "")
to handle both Unix (.tar.gz) and Windows (.zip) archive formats correctly.
- Add windows_amd64 platform to wasi-sdk.json with verified SHA256
- Add windows_amd64 to fallback registry in registry.bzl
- Checksum verified: 4a576c13125c91996d8cc3b70b7ea0612c2044598d2795c9be100d15f874adf6
- URL suffix corrected to x86_64-windows.tar.gz (matches actual release filename)

This fixes Windows CI failure where WASI SDK was reported as unsupported:
  Error: Unsupported platform windows_amd64 for wasi-sdk version 27

Windows platform was in JSON but had PLACEHOLDER checksum, and was missing
from the fallback registry used by get_tool_info().
Changed platform_mapping for windows_amd64 from "x86_64-mingw" to "x86_64-windows"
to match the actual GitHub release filename format.

This was causing 404 errors when downloading WASI SDK on Windows:
  Tried: wasi-sdk-27.0-x86_64-mingw.tar.gz (404 Not Found)
  Correct: wasi-sdk-27.0-x86_64-windows.tar.gz

The mingw suffix was incorrect - WASI SDK uses "windows" in their release filenames.
Go 1.25.0 does not exist, causing 404 errors when downloading on all platforms:
  Error: GET returned 404 Not Found
  URL: https://go.dev/dl/go1.25.0.windows-amd64.tar.gz

Updated to Go 1.25.3 which is the current latest stable release.
This affects TinyGo's hermetic Go SDK download for all platforms.
Windows Go distributions use .zip format, not .tar.gz:
  Failing: https://go.dev/dl/go1.25.3.windows-amd64.tar.gz (404)
  Correct: https://go.dev/dl/go1.25.3.windows-amd64.zip (✓)

Added conditional logic to select the correct archive format:
- Windows: .zip
- Linux/macOS: .tar.gz

This fixes TinyGo toolchain setup on Windows.
Replace Python scripts with Bazel-native solutions to fix Windows CI error 193.

Key changes:
- Make world attribute mandatory in wit_library for predictable filenames
- Use world_name.to_snake_case() + '.rs' pattern from wit-bindgen source
- Replace shell cp with file_ops component for cross-platform file copying
- Add concatenate_files operation to Go file_ops tool
- Update 27 wit_library targets across 15 BUILD files with world attribute

Eliminates 3 Python scripts from critical build path:
- wit/wit_bindgen.bzl: Python script for finding .rs files
- wit/symmetric_wit_bindgen.bzl: Python script for finding .rs files
- rust/rust_wasm_component_bindgen.bzl: Python concat script

Windows compatibility now 100% for WIT bindgen and Rust component paths.

Follows Bazel motto: Fast, Correct - Choose two (we get both with predictable
filenames and mandatory world attributes).
The multi_language_wasm_component rule was an experimental placeholder that
has been superseded by the official WAC (WebAssembly Composition) standard.

Changes:
- Removed wasm/multi_language_wasm_component.bzl (332 lines with Python bundling script)
- Removed from wasm/defs.bzl exports
- Replaced examples/multi_language_composition/BUILD.bazel with simple alias
- Updated examples/multi_language_composition/README.md to document wac_compose
- Updated ACHIEVEMENTS.md to reference wac_compose instead

Why this matters:
- Eliminates last Python bundling script (Windows compatibility)
- wac_compose uses official Bytecode Alliance WAC tool
- Better documented with working production examples
- Multi-profile support and component interconnection
- 6 working wac_compose examples vs 1 broken multi_language example

Migration path:
- For single component: Use direct reference or alias
- For multi-component: Use wac_compose with full composition language
- See examples: //examples/multi_profile, //test/integration:multi_service_system

All tests passing:
- //examples/multi_language_composition:all ✅
- //test/integration:integration_tests ✅
- //examples/basic:hello_component ✅

Closes #195
- Add source link for official WAC tool claim
- Add performance disclaimer (architectural vs measured)
- Clarify WIT package name mapping in migration example
- Add 'where possible' qualifier to zero-copy claim
…l docs

Add auto-generated API documentation for all rule files using Stardoc with
Astro frontmatter integration. Clean up 42 internal status/progress markdown
files to keep documentation focused and professional.

API Documentation (10 rule categories, 142K total):
- Create Stardoc targets for cpp, rust, go, js, wit, wasm, wkg, wac, wrpc rules
- Add Astro frontmatter to all generated docs using pure Bazel genrule
- Deploy generated docs to docs-site/src/content/docs/api/
- Total: 10 comprehensive API reference files auto-generated from source

Build System Improvements:
- Add missing bzl_library targets (wit_markdown, wac_bundle, wac_plug, etc.)
- Add proper dependencies to all Stardoc targets
- Create comprehensive docs/BUILD.bazel with organized sections

Docstring Fixes (Stardoc compatibility):
- Fix wkg/defs.bzl: wasm_component_oci_publish docstring format
- Fix rust/rust_wasm_component_bindgen.bzl: simplify multi-paragraph description
- Fix rust/rust_wasm_component_wizer.bzl: consolidate description
- Fix rust/rust_wasm_binary.bzl: simplify description

Documentation Cleanup (removed 42 files):
- Delete root-level status docs (ACHIEVEMENTS.md, HERMITICITY.md, etc.)
- Delete internal planning docs (DOCUMENTATION_PLAN.md, INTEGRATION_PLAN.md, etc.)
- Delete duplicate documentation (docs/examples/ directory)
- Delete Claude skill docs and internal tool notes
- Keep only user/developer-facing documentation

Result:
- Clean, professional documentation structure (94 → 52 files)
- Comprehensive auto-generated API reference
- Pure Bazel implementation (no shell scripts for doc generation)
- Ready for Astro/Starlight docs site integration
Fix syntax errors in BUILD files:
- docs-site/BUILD.bazel: add missing comma after glob()
- checksums/BUILD.bazel: add missing comma after glob()
- examples/oci_publishing/BUILD.bazel: add missing commas after enhanced_oci_annotations() calls

All files now pass buildifier formatting checks.
WASI interface packages (wasi:io, wasi:cli, etc.) export interfaces but don't
define worlds. The world attribute is only needed for component entry points,
not for interface library definitions.

This fixes CI build failures where WASI wit_library targets were missing the
mandatory world attribute.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants